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1 

2 PLUG AND PLAY INTERFACE FOR USER ACTIONS 

3 
4 

5 BACKGROUND OF THE INVENTION 

6 

7 1. Field of the Invention: 

8 The present invention relates to graphical user interfaces (GUIs) for use in 

9 computer systems and, more particularly, relates to a plug and play technique for 
y§ 10 manifesting a GUI in a manner which, among other things, enables its software 

M= 1 1 developers to implement certain user-requested or otherwise-initiated GUI code changes 

H ! 12 up to runtime, and in a modular manner which does not impact other GUI code. 
iU 13 

rt 14 2. Description of Prior Art: 

iff: 15 As virtually all users of computer terminals have experienced, user-interaction 

M= 16 with the computer, computer system, and/or computer network (including the Internet), in 

17 addition to keyboard interaction, generally involves positioning and activating a 

18 computer screen cursor, user-controlled by manually positioning a mouse and clicking its 

19 left and right mouse buttons. This mouse-cursor "subsystem", through operation of 

20 software including user interface software (or "framework"), permits users to activate a 

21 computer screen framework of menus, buttons, dialog boxes, toolbars, etc. The activity 

22 resulting in this framework information and other computer-screen-displayed information 

23 derived from this framework can be defined as the GUI. 
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1 

2 In GUI software development in the prior art, typically the code for operations is 

3 directly embedded into the message handler code that many user interface frameworks 

4 generate for menus, buttons, etc. Such code is compiled and linked into the overall 

5 application code module and is shipped to the customer-user in one unit. There are two 

6 main problems with this approach: (1) All code needed for the application is resident 

7 within a single module and has to be compiled and linked together. For large 

8 applications this can lead to long development times. Bug fixes in one part of the code 

9 can affect other parts of the code because there is no establishment and enforcement of 

10 boundaries between different parts of the code. (2) It is virtually impossible to add 

1 1 functionality on an as-needed or as-requested basis, during the development cycle or 

12 thereafter in response to developers' or users' desires, without recompiling, relinking, 

13 retesting, and reinstalling a great deal of functionally-unrelated code that should not have 

14 been affected at all by the added functionality. This is a very costly, time consuming, and 

15 wasteful repetition of code development, further running the risk of causing damage to 

16 code already in place. This is not an efficient manner in which to conduct software 

17 development. 
18 

19 Accordingly, software developers of complex software would like the flexibility 

20 to easily make changes to their software to effect GUI changes, in both software already 

21 supplied to users and in software still under development, without disrupting major 

22 portions of code already developed and finalized. In other words, they would like to be 

23 able to easily alter the software, which, in turn, alters the screen presentation or format, 

3 
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1 and they would like to be able to do this at any time, including after its shipment to a 

2 customer. Additionally, certain users such as, for example, major corporate purchasers of 

3 computer systems and equipment would like the flexibility to update or change available 

4 features or capabilities of GUIs supplied with their computer systems because their 

5 corporate needs change in response to their changing business conditions. This flexibility 

6 tends to be more difficult to achieve, however, as computer system performance 

7 requirements and expectations increase, whereby the software being developed, including 

8 GUI software, necessarily becomes more and more complex. 
9 

7f% 10 One approach that software developers have taken to simplify the software 

ha 1 1 development process involves their use of object-oriented languages, such as C++ and 

N s 12 JAVA, in writing their code. Briefly, an object, in computer software terms, is a 

m 13 dedicated area of memory which can be thought of as an impervious container holding 

r; 14 both data and instructions within itself, both defining itself and its relationships to other 

m 15 objects in the computer system or network. An object or node can send and receive 

fl 16 messages to and from other objects, respond and react to such messages (e.g. commands) 

17 but shall normally be impervious to internal scrutiny. For example, in a storage system (a 

18 kind of computer) each object (system object) may describe or relate to a specific 

19 tangible detail in the storage system or its processor (e.g. a fan, power switch, cache 

20 memory, power supply, disk drive interface, etc.), where these tangible objects in the 

21 storage system can send messages to each other and to other objects outside the storage 

22 system. The relationship between these specific objects in the storage system is usually 

23 visualized or characterized as a "tree" of objects. In a tree, each such object hangs off a 
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1 preceding object as if in a parent-child or inheritance relationship, with many children 

2 hanging from a parent not being an atypical configuration. In addition to these tangible 

3 kinds of objects, logical units (LUNs) are other nodes or objects that can be contained 

4 within the tree. For example, a storage system object can have several LUN objects as its 

5 children which, in turn, can have various disk objects as their children, etc. These kinds 

6 of objects are generically referred to herein as "system objects" since they all relate to a 

7 system or to components within a system, whether it is a storage system, computer 

8 system, disk drive system, or some other system, and representations of these objects are 

9 typically displayed on the GUI in this tree fashion. However, other kinds of objects can 
10 also be formulated which do not relate to a system or its components per se, such as 

- 1 1 objects relating to user actions and represented on the GUI in other ways. (User actions 

^ 12 are any commands or operations initiated by the user, such as, for example, creating a 

13 LUN or downloading new software to a disk, etc.) 



16 involves the concept of modularity, where software, whether object-oriented or 

17 otherwise, having common or related functionality is grouped together for control 

18 purposes. A first group then communicates with other functionally-unrelated groups of 

19 software through well-defined interfaces. This modular approach has resulted in certain 

20 notable efficiencies. In this approach, developers are organized into appropriate teams 

21 corresponding to the various groups, thus allowing parallel development. Also, this 

22 approach allows software development to proceed in a manner in which a particular 

23 group's software can be modified without negatively impacting other groups' software. 
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Another prior art approach to simplification in software development, in general, 
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1 However, this approach does not address inefficiencies noted above with regard to code 

2 modification after completion of the development cycle or after shipment to a customer 

3 user. 
4 

5 These shortcomings and inefficiencies of prior art techniques of software 

6 development, and particularly as relating to GUI software development are addressed and 

7 overcome by the welcome arrival of the present invention. 
8 

9 SUMMARY OF THE INVENTION 

10 Embodiments of the present invention include apparatus, method, system, and/or 

l ] computer program product for enabling software developers with a special plug and play 

1 2 technique for handling code development for a product. This technique not only permits 

13 code changes during the code development cycle which do not impact other code in the 

14 product beyond a minimal and immediate code relationship, but also permits code 

15 changes after the code development cycle and at any point up to user runtime that also do 

16 not impact other code in the product beyond such minimal and immediate code 

17 relationship. In addition, even after runtime, these embodiments allow ease of 

18 modification of the code to add additional features to the product to be supplied to the 

19 user as a product upgrade/enhancement, and/or to uncensor other features previously 

20 embedded in the code but censored from user access in a manner that such user did not 

2 1 know that such other features existed. 
22 
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1 In a particular aspect, embodiments of the present invention within a computer 

2 system relate to a plug and play interface for user actions. A file is established containing 

3 information about the user actions. The file is read to determine certain user actions to be 

4 implemented. The user is permitted to invoke or execute certain of those certain user 

5 actions through the user interface. The computer system can be part of a client server 

6 network. 
7 

8 In another aspect, embodiments of the present invention within a computer system 

9 relate to implementing a user interface. A text file is established in a memory in which 
J 10 all possible user actions are contained. A table is established in the memory. An 

m 1 1 application framework reads the text file to store certain user actions in the table. A 

H 1 12 minimum application requirement is established for the certain user actions. Each one of 

0* 13 the certain user actions is compared with its respective minimum application requirement. 

i/ 5 !' 14 For any of the user actions that meet the minimum requirement , it is determined if such 

ffj 

- 15 "any" is available. And, those user actions determined as "is available" are performed. 

C 16 

17 In yet another aspect in a client-server environment, embodiments of the present 

18 invention relate to a client having a user interface and a memory including a table for 

19 storing at least menu items of the user interface. A determination is made about which 

20 user actions shall be displayed on, and communicated to the network through, the user 

21 interface. A file is read and menus and menu-items of the file are stored in the table. The 

22 user selects one of the menus, and the user-selected menu to be displayed on the user 

23 interface is detected. If the user-selected menu is either a popup or main menu, the table 

7 



Assignee docket No: EMC-01-054; Attorney docket No. JW-EMC-010 PATENT 

1 is consulted to get a selected menu corresponding to the user-selected menu. For each 

2 menu item corresponding to the selected menu, "isAvailable" is called where each such 

3 menu item is shown in a visual state of either normal or grayed-out. If normal, 

4 "actionPerformed" is called to perform the selected action. If grayed out, the 

5 actionPerformed call is bypassed. This is repeated until all of the actions have been 

6 determined. 
7 

8 It is thus advantageous for application programmers to use embodiments of the 

9 present invention to develop code for actions (such as, for example, displaying a dialog or 
10 10 performing an operation on an object such as "reboot the computer") separately from an 
^ 11 application framework for at least the following reasons. First of all, there is a very 

!T 12 attractive and convenient plug and play aspect of the present invention wherein functional 

'J 13 modules can readily be added to ("plugged-into") the framework software up to runtime. 

Ci 14 These modules add functionality which the framework application software can then 

81 15 manifest in/on the GUI responsive to user requests ("play") in a manner that such 

'¥= 16 functionality appears seamless, and not modular or discrete, to the user. This seamless 

17 appearance provides a marketing advantage for the developer over other suppliers of 

18 software having a non-seamless feel, (not to mention the plug and play ease-of-use 

19 advantage provided for the user ). Secondly, upgrades to the shipped product containing 

20 embodiments of the present invention are readily made without impacting modules 

21 already in place. Thirdly, any code fixes that are required for one module will not impact 

22 another module. Only the module for which code changes are required will have to be 

23 rebuilt and relinked. Since no other modules need to be modified, development time is 

8 
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1 reduced. There are also advantages for users of embodiments of the present invention (in 

2 addition to the user advantage alluded to above), such as being able to request 

3 enhancements to their GUIs, which the developers can then supply quickly at minimal 

4 cost and with minimal disruption to current systems' operations, thus providing a 

5 convenience-advantage for users. 
6 

7 It is therefore a general object of the present invention to provide an improved 

8 computer system or client server network that employs a GUI. 
9 

kg io It is another general object of the present invention to provide improved 

H 11 distributed management software. 

E 12 

5 y 13 It is a further general object of the present invention to provide an improved 

CJ 14 technique for generating a GUI. 
S 15 

M= 16 It is a still further object of the present invention to provide an improved 

17 technique for creating a GUI by controlling the operative coupling between functional 

18 modules relating to user actions on the one hand and application framework software 

19 which provides infrastructure of the GUI on the other hand. 

20 

21 Other objects and advantages will be understood after referring to the detailed 

22 description of the preferred embodiments and to the appended drawings wherein: 
23 
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1 BRIEF DESCRIPTION OF THE DRAWINGS 

2 Fig. 1 is a block diagram of a client server network having multiple storage 

3 systems in which embodiments of the present invention are particularly useful; 

4 Fig. 2 is a schematic diagram of the inter-relationship between and among certain 

5 software components which are related to embodiments of the present invention; 

6 Fig. 3 is a schematic diagram of a text file stored in memory illustrating at least 

7 various menu sections, menu-items, and object class names which all relate to 

8 embodiments of the present invention; 

9 Fig. 4 is a schematic diagram of a GUI screenshot reflecting various menu options 

10 available through use of embodiments of the present invention; 

1 1 Fig. 5 is a flowchart of operation of embodiments of the present invention in 

12 context of usage by software programmers; and, 

13 Fig. 6 is a flowchart of operation of embodiments of the present invention in 

14 context of usage by a customer-user. 

15 

1 6 DESCRIPTION OF THE PREFERRED EMBODIMENTS 

17 Figure 1 - Client Server Network 

18 Referring to Fig. 1, there is shown a block diagram of a client-server network of 

19 the type in which embodiments of the present invention can be particularly useful, 

20 although it must be understood that embodiments of the present invention can be useful 

21 in any context in which a GUI is used. Client workstation 101 contains a computer 

22 system 108 having a memory and terminal with screen. The GUI, typically includes 

23 terminal, keyboard and mouse (not shown) through which a human user can interact with 

10 
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1 the network. Client workstation 101 is connected to server and storage systems 102, 103 

2 and 104 via bidirectional buses 105, 106 and 107 respectively. The dots between storage 

3 systems 103 and 104 are intended to imply that many more servers and storage systems 

4 can be operatively coupled to the workstation, but are not shown herein for purposes of 

5 enhancing clarity of presentation. Embodiments of the present invention are contained 

6 within client 101 . A context in which these embodiments can be especially useful is 

7 within the context of distributed management software running on, and distributed 

8 throughout, this client server network. One such distributed management software 

9 product is marketed under the trademark Navisphere® management software, which is a 
v _ 10 product offering of the current assignee of the present invention. However, as noted, the 
M= 1 1 present invention is not limited to this or any other specific context and can be utilized in 
J 5 12 any system in which a GUI is employed. 

^ 13 

y 14 Figure 2 -Software Schematic Overview 

gl 15 Fig. 2 is a schematic diagram showing an overview of the inter-relationship 

M= 16 between and among software components related to embodiments of the present 

17 invention. It must be understood that these software components are running on 

18 computer system 108 in client 101 of Fig. 1. Operating system software 201 is shown 

19 supporting application framework software 202, or, in other words, application 

20 framework software 202 runs on operating system 201 . Framework software 202 serves 

21 to provide a GUI framework or infrastructure for supporting additional GUI-related 

22 information. For example, framework software 202 provides a computer screen outline 

23 of main menu space generally located at or near the top of the terminal screen and 
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1 generally disposed horizontally across the screen. Framework 202 also provides various 

2 toolbars which typically abut each other and run horizontally under the main menu space, 

3 There may be other visual infrastructure provided by the framework which, in 

4 combination with the main menu and toolbars, contributes to computer terminal screen 

5 presentations that are familiar to computer users. Menus, menu-items, toolbar buttons 

6 and other visual representations of user-controlled functions can be displayed within the 

7 framework's visual infrastructure. However, the framework software does not, by itself, 

8 have detailed GUI information about these functions; i.e. the framework software does 

9 not know what information is in the menus, or what the menu items are, or what action(s) 
~*nl0 to invoke when a particular menu item is selected by the user, etc. 

: 11 

12 To obtain this detailed information, framework software 202 is operatively 

p J 13 coupled as shown by the bidirectional arrow to text file(s) software 203 which contains 

H 14 information about every possible menu and menu-item that is then being made available 

4 15 by software developers to users within a particular application context. [Text file(s) 203 

lI 16 could be one or more files, where all such information could then be contained in subsets 

17 spread over all of the files, where only certain of those files could then be available to 

18 certain users.] This menu and menu-item information, in text format, is in a language 

19 such as extensible Markup Language (XML). This information is sufficient to permit the 

20 computer system, under certain conditions, to ultimately manipulate each menu, menu- 

21 item, and action linked to each such menu item listed in the file in a manner to allow their 

22 respective appropriate presentations on the terminal screen under user control. XML 

23 language is a convenient language for developers to use in generating such information. 
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1 XML is used to define static information, such as names of menu items, name of the 

2 action, etc. However, in order to fabricate embodiments of the present invention, another 

3 language is needed. Java is chosen for that purpose as it is used to describe the dynamic 

4 part, i.e., the action that is executed. Accordingly, framework 202 reads text file 203 and 

5 converts information from text file 203 into Java object code. These Java objects are 

6 stored in menu/menu-item table 204, shown operatively coupled by a bidirectional arrow 

7 to framework 202. Each Java object in table 204 has a corresponding entry in XML 

8 language in text file 203. In operation, these Java objects are called by the framework in 

9 response to user commands, to be discussed in more detail with respect to other figures 
10 hereinbelow. 

11 

12 Another table, system-object table 212, is also shown operatively coupled by a 

r bidirectional arrow to framework 202. This table contains object information about the 

14 user's system which interfaces with the user at the GUI. (The user's system is depicted 

15 herein as a client server network, as exemplified in Fig. 1, but it should be understood 

16 that virtually any kind of computer system employing a GUI can be benefited by 

17 including embodiments of the present invention.) This table thus contains object 

18 information about the system's objects, such as, for example, disk drives, logical units 

19 (LUNs), storage processors (SPs), fans, switches, etc. Representations of these objects 

20 are displayed on the GUI, typically in an object tree format, and objects can be selected 

21 by the user by way of the usual screen cursor and mouse-click operation. Selection of 

22 such object representation from the terminal screen is sent to Framework 202 which uses 

23 it to find the appropriate and corresponding menu/menu-item object in table 204, and 

13 
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1 depending on certain conditions to be described can allow a GUI display of such 

2 menu/menu-item. These certain conditions relate to functional modules, such as software 

3 modules 205, 206 and 207. 
4 

5 These modules represent different sets of functionality to be made available to the 

6 user. Examples of generic sets of functionality are: "Manager", "Analyzer" and 

7 "Organizer", defined as follows: 

8 (1) "Manager" manages the system and displays its results. In the 

9 instance of a RAID storage system within a client-server network, Manager 

10 permits all basic functions of the array of disk drives, such as creating LUNs. 
- 1 1 (2) "Analyzer" analyzes performance of the system and displays its 

12 results. Analyzer permits one to graph performance of certain objects. 

13 (3) "Organizer" organizes files in the system and displays its results. The 

14 Organizer functional module can thus place a menu item called, for example, 

15 "Folder Management" into the main menu with an option under it called "create 
■ 16 folder". 



17 When a menu item for any of these functional modules is chosen or selected by the user, 

18 for example, "create folder", the framework signals the Organizer software module that 

19 the "create folder" menu item has been selected (clicked-on) and that the Organizer 

20 should do whatever it needs to do to properly respond. Similarly, the other modules 

21 would do what they need to do if one of their menu items was "clicked-on" by the user. 

22 The framework software does not have capacity to know or interpret what this or any 

23 particular menu item means, but does know that this "create folder" selected menu item 
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1 belongs to the Organizer module and thus knows which module to signal for response. It 

2 should be understood that there could be many more modules plugged-in to the 

3 framework, with no theoretical upper limit, and that only three modules are shown herein 

4 as being plugged-in to enhance clarity of presentation. 

5 

6 Each of these functional modules must "plug-in" to the framework software 

7 through an interface, namely interfaces 208, 209, and 210. Suffice it to say in this 

8 software overview section that these interfaces are Java code software which operates 

9 between framework software 202 and any one or more of plugable modules 205, 206, and 
#1 10 207 respectively. More detail is given hereinbelow about the makeup of the interfaces, 

H= 1 1 and how they operate with both the modules and the framework. Also shown is a fourth 

^* 12 module 21 1 which may be intended to plug in as suggested by dashed arrow 213, but is 

1 y 13 not plugged-in, as there is no interface available for module 211. More will be presented 

%j 14 about this situation hereinbelow. 
cn 15 

M 16 Figure 3 - Text File 

17 Fig. 3 is a schematic diagram of a simplified version of a text file, such as file 203 

18 of Fig 2, containing information stored in binary in memory and is provided herein to 

19 enhance clarity of presentation. (An actual text file portion is provided in a Table I 

20 hereinbelow, about which more will be said later.) Code written to and read from the text 

21 file by the software developers is in textual format, as, for example, in XML language, 

22 and therefore is human-readable. The text file is sequenced or ordered in a particular 
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1 manner where, in this case, the "main menu" section is first, the "toolbar" section is next, 

2 and the "object menus" section is last. 
3 

4 There is shown in this illustration in the main menu section both a "file" menu 

5 and an "edit" menu. A main menu section can have many more entries than two, and 

6 need not have these two particular entries. Only two entries or menus are illustrated 

7 herein to enhance clarity of presentation. Thus, in the file menu there is contained both a 

8 "new" menu option or item and a "save" menu option or item. Associated with the new 

9 menu item is the name of its object class "file new action", otherwise known as the 

i io "action". Similarly, associated with the save menu item is the name of its object class 

11 "file save action", also otherwise known as the "action". In operation, the "file new 

12 action" class gets invoked (which means selected, or drafted into service) when "new" is 

13 selected by the user' s left-clicking of the mouse when the cursor is pointing on the screen 

14 to "New" in the pop-up menu under the File button on the main menu. Similarly, the 

15 "file save action" class gets invoked when "save" is selected by the user's left-clicking of 

16 the mouse when the cursor is pointing on the screen to "Save" in the pop-up menu under 

17 the Save button on the main menu. 

18 

19 The "edit" menu can be similarly described. In the "edit" menu there is contained 

20 both a "cut" menu option or item and a "copy" menu option or item. Associated with the 

21 cut menu item is the name of its object class "edit cut action", otherwise known as the 

22 "action". Similarly, associated with the copy menu item is the name of its object class 

23 "edit copy action", also otherwise known as the "action". In operation, the "edit cut 
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1 action" class gets invoked when "cut" is selected by the user's left-clicking of the mouse 

2 when the cursor is pointing on the screen to "cut" in the pop-up menu under the Edit 

3 button on the main menu. Similarly, the "edit copy action" class gets invoked when 

4 "copy" is selected by the user's left-clicking of the mouse when the cursor is pointing on 

5 the screen to "Copy" in the pop-up menu under the Edit button on the main menu. 
6 

7 Next, the "toolbar" section is provided in the text file. This illustration is intended 

8 to suggest a generic toolbar, and multiple toolbars are also intended to be suggested by 

9 this illustration. Thus, there could be multiple toolbar sections in the text file, one after 

10 the other, where all toolbars capable of being displayed on the screen have a 

1 1 corresponding toolbar entry stored in the text file. Under the particular toolbar section 

12 illustrated, two "buttons" are shown, (more than two can be used; only two are shown to 

13 enhance clarity of presentation). "Button 1" is a first toolbar button (which could be 

14 conceptualized as a menu option or item) and the name of its object class is "button 1 

15 action". "Button T is a second toolbar button (which again could be conceptualized as a 

16 menu option or item) and the name of its object class is "button 2 action". Again, either 

17 class can get invoked in a manner similar to main menu operation described above, when 

18 the user clicks on the appropriate button on the screen. Under the button 1 menu option 

19 in Fig. 3 is shown "icon" and "label" which refer to specific visual means for identifying 

20 button 1 on the user interface terminal screen; typically, the icon is a small picture 

21 overlaying the button on the screen and suggesting the button's functionality, and the 

22 label is typically one-word in human-readable language also identifying such 

23 functionality, the label appearing on the screen when such button is clicked-on or 
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1 highlighted by the user' s mouse-cursor interaction. These buttons can be assigned 

2 specific functionality by operation of specific modules plugging-in to the framework, 

3 which operation will be discussed in more detail below. 
4 

5 Finally, the third depicted section is "Object Menus", which can be associated 

6 with a tree item in the tree presentation on the user interface screen. These objects are 

7 system component objects, including, for example, disk drives, storage processors, 

8 servers, LUNs, fans and other cooling mechanisms, and various nodes throughout these 

9 and other system components, etc. These objects could thus number in the multiple 

10 thousands or more for a typical client-server storage system. To enhance clarity of 

1 1 presentation herein, only two menus having a total of three menu options are shown, 

12 namely: "Disk" and "Lun" are shown as menus, and under the Disk menu is presented 

13 three menu options or items - "delete", "properties" and "graph". The "names of the 

14 class" or "action" for each menu item are "disk delete action", "disk properties action" 

15 and "disk graph action" respectively. The operation for invoking any of these actions is 

16 the same as earlier described with respect to the main menu operation and the toolbar 

17 operation. 
18 

19 A text file can contain some or all of the currently-available functionality that 

20 could be expressed on the user-interface terminal screen. Accordingly, as noted earlier, 

21 there could be different text files for different categories of customer each file having a 

22 special subset of all of the currently available functionality, or there could be one 

23 universal text file containing all currently available functionality for all customer-users. 
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1 What actually gets expressed or manifested on the terminal screen, however, can be a 

2 further subset of the total functionality stored in any particular text file. This further 

3 subset is determined by which modules (see Fig. 2, modules 205, 206, 207) are plugged- 

4 in to the framework. Thus, the text file and its corresponding menu/menu-item table 

5 contain functionality as a potential availability for a particular customer through software 

6 which is installed and running on such customer's system. But, without the appropriate 

7 module being plugged into the framework, which holds the "key" to unlock such 

8 potentially available functionality, it remain hidden from the user's view and access 

9 despite being installed and running on user's system. The subject of these modules will 
5 10 be discussed in more detail hereinbelow. 

Ull 

M= 12 Accordingly, this text file which is written and accessed in XML language, offers 

^ 13 the software developers a significant degree of flexibility in their writing of code in that 

JT { 14 changes to existing text files are easily made. Thus, in the normal course of software 

15 development, if there were to be additions or deletions to any of the menus in any of the 

fl 16 sections in the text file illustrated in Fig. 3, such additions and deletions are easily made 

17 in XML directly into the file in the proper sequence and location. Furthermore, any 

18 special functionality that may be desired by any particular user or potential user 

19 (prospective customer) can easily be added to a pre-existing text file. To make use of any 

20 such additions including this special functionality, additional modules will allow such 

21 functionality to be expressed on the user-interface terminal screen. These additional 

22 modules can be added to the pre-existing modules 205, 206 and 207 of Fig. 2. These 
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1 modules and additional modules and their operation will be discussed further 

2 hereinbelow. 

3 

4 Framework software 202 reads text file 203 when the framework is installed and 

5 starts up. The file is read completely, from the beginning of the main menu through the 

6 last entry under the object menus. The framework saves this entire text file information 

7 in memory in Java object language by way of the menu/menu-item table 204. Thus, if 

8 main menu item "new" was selected by the user, the framework consults table 204 where 

9 a determination is made whether or not to invoke the "file new action class". As noted 
=|3 10 above, whether or not this class gets invoked is dependent upon the which modules are 

ll plugged in to the framework which may be interpreted as being dependent upon which 

J 12 modules are appropriately interfaced with the framework. 

Ci 14 The interface (208, 209, 210 of Fig. 2) is written in Java code and is essentially 

fti 

ffi 15 the combination of two components, namely: content of Table I hereinbelow in 

Ms 16 functional operation with content of text file 203 (as written in Java and stored in the 

17 menu/menu-item table 204). 

18 



19 TABLE I 

20 INTERFACE IN JAVA CODE 

21 



22 

23 interface IWfxAction 

24 { 
25 

26 // determine whether the action is available 

27 boolean isAvailable{ INaviObject [] naviObjects ); 
28 

29 // the action has been chosen by user, execute it 

30 void actionPerformed( INaviObj ect [ ] naviObjects ) ; 
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1 } 
2 

4 This code of Table I contains two "methods" which are "is Available" and 

5 "actionPerformed". These methods and this code shall be discussed in connection with 

6 popup menus shown in Fig. 4 hereinbelow. 

7 

8 In connection with this discussion on text files and on the simplified text file 

9 version 300 of Fig. 3, there is further presented in TABLE II hereinbelow a print-out of 

10 an actual text file written in XML language and used in an embodiment of the present 

1 1 invention. This TABLE II reflects the following three sections - MAIN MENU, 
2 12 TOOLBAR, and OBJECT MENUS : 

13 MAIN MENU (1) File Menu with its Login, Logout, Select Devices, New 

fU 14 Window and Exit menu options or items; (2) View Menu with its Toolbar, Taskbar and 

3 15 Event Viewer Bar menu options or items; (3) Window Menu with its Cascade, Tile 

Jjf 16 Vertically, Tile Horizontally and Close All menu options or items; and (4) Help Menu 

17 with its Help Topics and About menu options or items. 

18 TOOLBAR (1) Software Installation button; (2) Help button. 

19 OBJECT MENUS LUN (1) Set Name menu item; (2) Delete menu item; (3) 

20 Properties Menu item (4) Change Name menu item. 
21 

22 The Change Name menu item is italicized since it does not appear in the table, but 

23 is inserted herein to illustrate the simplicity of accomplishing an upgrade to the text file. 

24 For example, to insert this additional menu item and upgrade the text file, one merely 

25 accesses the text file and writes to it by typing on the keyboard the same syntax shown 

21 
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1 and inserts "Menultem Label = "Change Name" Mnemonic= etc., and another menu item 

2 is born in the text file. 

3 

4 TABLE II 

5 TEXT FILE 203 IN XML 

6 

7 
8 

9 <JNfxUIPlugPoints> 
10 

11 <MainMenu> 
12 

13 <Menu Label =" Pile" Mnemonic="F" > 

14 

15 <MenuItem Label=" Login . . . " Mnemonic="L" 

16 Action= "LoginDialogAction" ></MenuItem> 
17 

J8 <MenuItem Label=" Logout" Mnemonic= "o" 

19 Action= "LogoutDialogAction" ></MenuItem> 

:20 

;21 <Separator></Separator> 
22 

23 <MenuItem Label="Select Devices..." Mnemonic="S" 

24 Action="DeviceSelectionAction" ></MenuItem> 
25 

26 <MenuItem Label="New Explorer Window" Mnemonic="N" 

27 Action="NewExplorerAction"x/MenuItem> 
28 

29 <Separatorx/Separator> 
30 

31 <MenuItem Label="Exit" Mnemonic ="x" 

32 Action = "ExitAction"x/MenuItem> 
33 

34 </Menu> 
35 

36 <Menu Label="View" Mnemonic="V" > 

37 

38 <MenuItem Label="Toolbar" Mnemonic="T" CheckBox="true" 

39 Action="ShowToolbarAction" ></MenuItem> 
40 

41 <MenuItem Label="Taskbar" Mnemonic="0" CheckBox="true" 

42 Action="ShowTaskbarAction" ></MenuItem> 
43 

44 <MenuItem Label="Event Viewer Bar" Mnemonic="E" 

45 CheckBox=" false" Action="ShowEventVie-werBarAction" ></MenuItem> 
46 

47 </Menu> 
48 

49 <Menu Label =" Window" Mnemonic= "W" > 
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1 

2 <MenuItem Label=" Cascade" Mnemonic ="C" 

3 Action="CascadeWindowAction" ></MenuItem> 
4 

5 <MenuItem Label="Tile Vertically" Mnemonic="V" 

6 Action="TileWindowVerticalAction" ></MenuItem> 
7 

8 <MenuItem Label="Tile Horizontally" Mnemonic="H" 

9 Action="TileWindowHorizontalAction" ></MenuItem> 
10 

11 <MenuItem Label="Close all" Mnemonic="a" 

12 Action="CloseWindowAction"x/MenuItem> 
13 

14 </Menu> 
15 

16 <Menu Label="Help" Mnemonic="H" > 
17 

18 <MenuItem Label="Help Topics..." Mnemonic="H" 

19 Ac t i on= " He lpTop i c s Ac t i on " >< /Menul t em> 
20 

ill <Separatorx/Separator> 
22 

23 <MenuItem Label= "About ... " Mnemonic="A" 

24 Action= "HelpAboutAction" ></MenuItem> 
25 

26 </Menu> 
27 

28 </MainMenu> 
29 

30 <MainToolbar Label=" Toolbar" > 
31 

32 <Button Icon="ICON_SWINSTALL16" 

33 Action= "Soft ware InstallationAct ion" ></Button> 
34 

35 <Button Icon="ICON_HELP16" Action="HelpTopicsAction" ></Button> 
36 

37 </MainToolbar> 
38 

39 <Obj ectMenus> 
40 

41 <Menu ForObjectType="LUN"> 
42 

43 <MenuItem Label="Set Name..." Mnemonic="S" 

44 Action= "LunActions ">< /Menul tem> 
45 

46 <MenuItem Label="Delete" Mnemonic="D" 

47 Act ion="LunAct ions ">< /Menul tem> 
48 

49 <MenuItem Label="Properties . . . " Mnemonic="P" 

50 Action= "LunActions" ></MenuItem> 
51 

52 </Menu> 
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1 

2 </ObjectMenus> 
3 

4 </JNfxUIPlugPoints> 

5 

6 

7 Figure 4 - GUI Screenshot Schematic 

8 There is shown in Fig. 4 a schematic diagram of a GUI screenshot reflecting 

9 various menu options available through use of embodiments of the present invention. It 

10 should be understood that all of these menu options would not be simultaneously 

11 displayed in an actual screenshot, where only one drop down menu, or only one popup 
.^12 menu is displayed at any given time. However, for purposes of providing a complete 

13 explanation of the operation of the present invention, Fig. 4 reflects multiple operations 

fri 14 superimposed or displayed on the screen at the same time, which is understood to not be 

O 15 possible under current technology. 
L 16 

-J? 17 Referring to the upper portion of Fig. 4, main menu or main menu bar 401 is 

18 shown containing multiple menus: File, View, Window, Help, Edit, Manager, Analyzer, 

19 and Organizer. More menus and/or others could have been shown. As each of the 

20 "buttons" or "icons" or "texts" identifying these menus are highlighted by the screen 

21 cursor and left-clicked-on by operation of the mouse, its respective popup menu is 

22 displayed. Accordingly, if "File" is clicked-on, then a popup menu appears displaying 

23 the following menu items: Login, Logout, Select Device, New Window, and Exit. If 

24 "View" is clicked-on, then a popup menu appears displaying the following menu items: 

25 Toolbar, Taskbar and Event Monitor. If "Window" is clicked-on, then a popup menu 

26 appears displaying the following menu items: Cascade, Tile Vertical, Tile Horizontal, 
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1 Close All. If "Help" is clicked-on, then a popup menu appears displaying the following 

2 menu items: Help Topics and About. If "Edit" is clicked-on, then a popup menu appears 

3 displaying Select All and Find. If Manager is clicked on, a popup menu appears 

4 displaying Create New Volume. If Analyzer is clicked on, a popup menu appears 

5 displaying Graph, and if the Graph menu item is highlighted and clicked on, a graph as 

6 shown may appear under certain circumstances to be discussed below. Finally, if 

7 Organizer is clicked-on, a popup menu appears displaying Create Folder. As noted 

8 above, only one of these popup menus can appear on the screen at any given time, but are 

9 shown in multi-display herein for purposes of providing full explanation. User selection 
ll'j 10 of any one of these menu items shall be described below in connection with discussion of 
j} ! 11 operation of the present invention. 

iS 12 

5 l 13 Immediately below and abutting the display of the main menu on the screen is a 

Si 14 ghost outline of a series of three toolbars, pointed to generally by reference numeral 402 

CH 15 with arrow in dashed-line format. These three toolbars are also pointed to generally by 

^~ 16 reference numeral 402 with arrow in solid-line format. They are shown as toolbars 403, 

17 403, and 405, and, for purposes of enhancing clarity of presentation, are shown as being 

18 displaced from what would have been their actual locations abutting main menu 401 . 
19 

20 Finally, also displayed on the screen is object tree 406 showing a tree of system or 

21 system component objects (object representations) which can be stored in system object 

22 table 212 or the like. Displayed are visual representations of objects for System, its 

23 Subsystem 1, and LUNs 1, 2, and 3 belonging to Subsystem 1. The Fig. reflects a popup 
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1 menu associated with LUN3. (There can be a huge number of system component objects, 

2 and only a small number are shown to enhance clarity of presentation.) 

3 

4 The visual display of Fig. 4 maps closely to the text file of Table II. For example, 

5 the following menus: File, View, Window and Help in the main menu Bar of Fig. 4 are 

6 expressed in proper XML syntax and code in the text file of Table II. Under each of 

7 these menus in the text file is expressed their respective menu items as displayed in Fig. 

8 4, also in proper XML syntax and code. For example, under <Menu Label= "File" 

9 Mnemonic="F"> there is <MenuItem Label="Login..." Mnemonic- 'L" Action= 

10 "LoginDialogAction"/>. And what follows in the text file are similar code expressions 

] J involving "LogoutDialogAction", "DeviceSelectionAction", and "ExitAction", which 

1 2 are reflected in the File popup menu of Fig. 4. 

14 In next sequence, Toolbar 403 in Fig. 4 is listed in Table II, its "S" button 

15 corresponding to "SoftwarelnstallationAction" and its "H" button corresponding to 

16 "HelpTopicsAction". And, thereafter, Object Tree 406 in Fig. 4 is listed in Table II as 

17 <ObjectMenus> having "SetName", "Delete", and "Properties" associated with 

18 "Lun Actions" which are shown in Fig. 4 associated with LUN3 in a popup menu. 

19 

20 In operation, referring to Figs. 2 and 4 and to Tables I and II, a user positions the 

21 cursor on the screen over a displayed representation of an object, namely: a particular 

22 icon, button, or text. This positioning highlights the selection, and the user left-clicks on 

23 such selection causing a popup menu to occur. The following activity is manifested. On 
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1 the one hand, if the user-selected object is a system object as in Object Tree 406, the 

2 framework software consults table system object table 212 and thereby identifies or 

3 obtains that object from table 212. On the other hand, if the user-selected object is a 

4 menu, the framework software this time consults menu/menu-item table 204 and thereby 

5 identifies or obtains that object from table 204. In either case, the framework software 

6 will call method #1 ("isAvailable") causing "INaviObject[] naviObjects" to become 

7 whatever object was identified from either table. If this software operation determines 

8 that the user- selected object is, in fact, available, then all of its respective menu items in 

9 its popup menu may not be greyed-out on the screen and thus all menu items will be 

1; 10 made accessible to the user. Alternatively, some of the menu items may be greyed-out 

« 1 1 making those inaccessible by the user, where the remaining menu items which are not 

5 12 greyed-out are then accessible by the user. However, in the extreme circumstance, it is 

. 13 possible that all of the menu items can be greyed-out. If at least some of the menu items 

i 14 are not greyed-out and if the user then decides to execute the action by clicking on one of 

•15 the menu items that are not greyed-out, the framework calls method #2 

■ = 16 "actionPerformed". This system call again causes "INaviObject[] naviObjects" to 

17 become whatever object was selected by the user which, in turn, causes the software to 

18 perform whatever function is represented by that selected menu item or object. The 

19 foregoing description is applicable to any of the displayed menus, buttons, or objects 

20 shown in Fig. 4. 

21 

22 Referring to the text file of Table II, if a product is being prepared for shipment 

23 which contains, for example, only the functionality in this text file, then toolbar 403, 
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1 object tree 406, and menus: File, View, Window, and Help are all included in the shipped 

2 product. But, other menus shown in Fig. 4, namely: Edit, Manager, Analyzer and 

3 Organizer, are excluded from this shipped product. If at some point either during 

4 development, or after shipment, or any time before runtime, either developers or 

5 customer decides to include additional functionality in the product, such as Manager, 

6 Analyzer and Organizer, it can be accomplished easily through application of the present 

7 invention. For example, referring to Fig. 2, module 205 can represent Manager, module 

8 206 can represent Analyzer and module 207 can represent Organizer. Each module 

9 represents a potential modification to text file 203 which gets modified appropriately to 
■J 10 accommodate these additional functionalities. The two "isAvailable" and 

^ 11 "actionPerformed" Java code methods for each additional functionality are effectively 

-j 1 2 integrated with each such modification by operation of the framework software in 

b 13 cooperation with text file 203 and with table 204. Each of the methods are part of a Java 

SI 14 class. This class gets placed in a pre-determined place (directory); such place is specified 

15 in text file 203 since the name of the action class also includes a fully qualified pathname 

p ' 16 to that action class. Thus, this Java code in combination with its potential effect on 

17 modules being added into text file 203 are the equivalent of interfaces 208, 209, and 2 1 0 

18 for modules 205, 206, and 207 respectively. In this manner, each module can be readily 

19 added to text file 203, which, in turn, gets added to menu/menu -item table 204 when the 

20 framework reads the text file. The framework reads the text file at runtime, whereby 

21 module insertions (and/or deletions) can readily take place at any time up until runtime. 
22 



28 



JlllIIftlllUFKI 



Assignee docket No: EMC-01-054; Attorney docket No. JW-EMC-010 PATENT 

1 It should be noted that use is made of Java code in both menu/menu-item table 

2 204 and system object table 212 where their objects are formulated in Java language. 

3 One reason for employing Java language at this juncture in the system is that Java has 

4 capacity to absorb such modifications at a relatively late point in the software 

5 development cycle. Java code does not become machine code until runtime and 

6 modifications cannot be made to the code after it becomes machine language or code. In 

7 other words, Java source code, which is written and understood by humans, is run 

8 through a compiler to look for source code errors and produce "bytecode" which is 

9 understood by other software called a Java interpreter. At runtime, when the system is to 
K) be run for the first time at a customer site, the Java interpreter then translates the byte 

1 1 code into machine language (l's and 0's) for the system's processor. Accordingly, one 

12 has until runtime to make these module insertions if Java is used. But, by contrast, if 

1 5 another object-oriented language, such as C++, for example, was used, then the time to 
14 make such module insertions would have been constrained to prior to compilation which 
] 5 occurs immediately after source code preparation and therefore occurs at a much earlier 

16 stage in the software development cycle. 
17 

18 Next, considering module 21 1 of Fig. 2, it is shown with dashed arrow 213 

19 pointing to framework 202 to imply that one may wish to insert such module as yet 

20 another addition to text file 203. No interface is shown to accommodate module 21 1 in 

21 Fig. 2. Thus, if such attempt is made after runtime, such insertion is not available, 

22 whereby no interface would exist. Also, even if before runtime, if a choice is made not to 

23 allow such insertion, then no interface would exist. Referring to Fig. 4, if the Edit menu 
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1 located in the main menu Bar is assumed to be directly derivable from Module 21 1 and is 

2 displayed on the screen as shown in Fig. 4, then it must be concluded that at some point 

3 an appropriate interface for module 21 1 was set in place in accordance with discussions 

4 above relating to the other modules. 
5 

6 In accordance with the above description, any menu in the main menu Bar or any 

7 toolbar button such as "S" or "H" in toolbar 403 (other toolbars not showing any 

8 buttons), or any object in object tree 406 could be clicked-on, and the above-described 

9 action would be set in motion. In any particular instance, the resulting popup menu items 
JO may be full or partially greyed-out, or not greyed-out at all as a function of the state of 

1 1 each such item's interface. For example, if Analyzer is selected by the user which 

12 provides the "graph" menu item, and if such menu item is available and is selected, the 
u user then executes an action resulting in graph 407 being displayed to illustrate results of 

14 some analysis such as, for example, a state of system performance. For another example, 

15 if the "System" is being queried by the user producing object tree 406, and if LUN3 is 

16 available and clicked-on, a popup menu showing "Set Name", "Delete", and "Properties" 

17 is shown. Any of these menu items could be chosen to be executed by the user if not 

18 greyed-out. "Change Name " is shown in Fig. 4 as italicized since it does not appear in 

19 the text file of Table II. However, it could easily be added to the text file as described 

20 above. 
21 
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1 Figure 5 - Flowchart - Developer's Operation 

2 Fig. 5 is a flowchart of operation of embodiments of the present invention in 

3 context of usage by software programmers. In step 501, a text file is established 

4 containing all possible menus and their respective menu items corresponding to all 

5 system objects being managed in the system. In other words, a text file such as, for 

6 example, text file 203, 300, or that shown in Table II is established. This is prepared in 

7 textual format as shown. All developers in the development team can contribute to this 

8 text file as it is being developed. All system objects of interest, which in the management 

9 of a storage system could number in the thousands of objects and more, can be included 
10 in such a text file. As noted, this file could be a multiplicity of files, each containing a 

■111 subset of the total number of possible menus and menu items. 
T 12 

13 Next, in 502 the Java interface code "isAvailable" and "actionPerformed" is 

_ 14 integrated into the software to be supplied to the user. As noted earlier, although these 

15 methods are part of a Java class, they have a pre-determined place specified in XML text 

■ 16 file 203 because the name of the action class also includes a fully qualified pathname to 

17 that action class. Such code shall operate on selected objects identified in a menu/menu- 

18 item table consulted by the framework software responsive to user requests. Then, in 

19 step 503, additional code for censoring is included by the developers into the software to 

20 be supplied to the user which eliminates availability of certain selected objects from 

21 objects otherwise available to the user. This censoring results in the user not even being 

22 . aware that such an object exists since such object is not displayed on the terminal screen. 

23 This feature permits the developers to uncensor such features at predetermined future 
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1 times and release such features as product enhancements without having to put more than 

2 minimal effort into any such software upgrade release at the time of its release. 

3 

4 Next, in step 504 the text file is read and all menus and their respective menu 

5 items are stored in menu/menu item table 204 as menu/menu item Java language objects. 

6 And, the last step 505 allows for testing and other usual software preparation prior to 

7 shipment of software or a software upgrade to the user. 
8 

9 Figure 6 - Flowchart - User Operation 

. io Fig. 6 is a flowchart of operation of embodiments of the present invention in 

§=* n context of usage by a customer-user. In step 601 the user installs and makes operational 

12 the software received after it is prepared in accordance with the steps of Fig. 5. This is 

5 " 13 runtime. In step 602 the user selects an object, either a toolbar button, a system object, a 

\J 14 menu text button in the main menu, or some other object as displayed on the terminal 

Ol 15 screen. In step 603, the menu corresponding to the user-selected object is detected. The 

I s * 16 algorithmic process then moves to step 604 wherein the query is made: is the detected 

17 menu a popup menu (e.g., associated with a system object as shown in object tree 406)? 

18 If not, a further query is made: is the detected menu the main menu? If not, the 

19 algorithmic process returns to step 602 and repeats. However, if the detected menu was a 

20 popup menu the algorithmic process moves to block 614 where system object table 212 is 

21 consulted after which menu/menu- item table 204 is consulted in step 606. By 

22 comparison, if the detected menu was a main menu , the algorithmic process moves 

23 directly to step 606. In other words, if the detected menu was associated with a system 
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1 object in object tree 406, (a popup menu) initially system object table 212 and then 

2 menu/menu-item table 204 are consulted by the framework to obtain a Java-coded 

3 particular menu corresponding to the user selected system object. But, if the detected 

4 menu is a main menu, then menu/menu-item table 204 is consulted directly by framework 

5 202 to obtain such Java-coded particular menu. Next, in step 608 the question is asked: 

6 for each menu item in such particular menu, is such item to be censored? This question is 

7 repeated until all menu items in the particular menu have been queried. For a system 

8 object, even if all menu items in the particular menu are to be censored, the system object 

9 will be viewable on the terminal screen anyway, since system objects need to be shown. 
10 But, for a non-system object, if all menu items associated with such non-system object 

] ] such as a text button object in main menu 401 were censored, then such button would not 

12 appear on the screen. Such text button could then be provided (made visible) at a 

13 subsequent time, as, for example, when a software "upgrade" is provided by the software 

14 developers. 
15 

16 Next, in step 609, for each uncensored menu item in the particular menu, a 

17 determination is made whether to show that menu item as normal or greyed-out by the 

18 framework software calling method #1, "is Available" on that action. On the one hand, in 

19 step 610, for each uncensored menu item for which that is true, such menu item is 

20 enabled (not greyed-out) in step 612. On the other hand, in step 610, for each uncensored 

21 menu item for which that is not true, the "no" arrow brings the algorithmic process to 

22 step 61 1 to "grey-out" or disable each such menu item. In either case, the algorithmic 

23 process moves to query block 613 where the question is posed: is the menu item 
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1 executed by the user? In other words, has the user left-clicked on the non-greyed-out 

2 menu item? If "yes", the process moves to block 607 and the framework calls 

3 "actionPerformed" on the action. In this affirmative case, the software (including 

4 whatever module, such as modules 205, 206, 207, etc. of Fig. 2, being associated with the 

5 selected menu item) performs its required task in response and the process returns to the 

6 input of step 602 where the user selects the next object. But, if "no", then step 607 is 

7 bypassed and there is no execution of this menu item. In this negative case there is no 

8 resulting action performed and the process again returns to the input of step 602 where 

9 the user selects the next object. Note that any menu item disabled via step 61 1 when 

10 queried in step 613 necessarily produces a "no" result, 
n 

12 The present embodiments are to be considered in all respects as illustrative and 

13 not restrictive. The flowcharts used herein to demonstrate various aspects of the 

14 invention should not be construed to limit the present invention to any particular logic 

15 flow or logic implementation. The described logic may be partitioned into different logic 

16 blocks, (e.g., programs, modules, functions, or subroutines) without changing the overall 

17 results or otherwise departing from the true scope of the invention. For example, as 

18 noted, there could be multiple text files, each containing a different subset of objects, 

19 where each of the different text files could be useful in different contexts respectively, 

20 and where the appropriate text file is automatically selected for the appropriate context, 

21 etc. The present invention may be used wherever a GUI is utilized, in any application, 

22 and may be embodied in many different forms, including, but not limited to, computer 

23 program logic for use with any kind of processor, programmable logic for use with any 



34 



'IIIMBIIHIILI'II 



Assignee docket No: EMC-01-0S4; Attorney docket No. JW-EMC-010 PATENT 

1 kind of programmable logic device, discrete components, integrated circuitry including 

2 application specific integrated circuits (ASICs), or any other means including any 

3 combination thereof. Computer program logic implementing all or part of the 

4 functionality described herein may be embodied in various forms, including, but not 

5 limited to, source code form, computer executable form, and various intermediate forms 

6 (e.g. forms generated by an assembler, compiler, linker, or locator.) Source code may 

7 include a series of computer program instructions implemented in any of various 

8 programming languages for use with various operating systems or operating 

9 environments. The source code may define and use various data structures and 

S 10 communication messages. The source code may be in computer executable form, or it 

JJT 11 may be in a form convertible into computer executable form. The computer program 

pi 12 may be fixed in any form either permanently or transitorily in a tangible storage medium, 

5 13 such as a semiconductor memory device, a magnetic memory device, an optical memory 

SJ 14 device, a PC card, or other memory device. The computer program many be fixed in any 

CP 15 form in a signal that is transmittable to a computer using any of various communication 

^ 16 technologies including, but not limited to, analog, digital, optical, wireless, networking, 

17 and internetworking technologies. The computer program may be distributed in any form 

18 as a removable storage medium with accompanying printed or electronic documentation, 

19 preloaded with a computer system (e.g. on system ROM or fixed disk), or distributed 

20 from a server or electronic bulletin board over the communication system (e.g., the 

2 1 Internet or World Wide Web) . 

22 
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1 Furthermore, applications for embodiments of the present invention are not 

2 limited to computer storage system environments. For example, embodiments of the 

3 present invention are applicable to a wide-ranging list of arenas such as medical 

4 applications, or space program applications, or any arena where menus and toolbar 

5 buttons on a GUI are being used and would benefit from the plug and play techniques 

6 disclosed and claimed herein. Therefore, the scope of the invention is indicated by the 

7 appended claims rather than by the foregoing description, and all changes which come 

8 within the meaning and range of equivalency of the claims are therefore intended to be 

9 embraced therein. 
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